home *** CD-ROM | disk | FTP | other *** search
/ Halting the Hacker - A P…uide to Computer Security / Halting the Hacker - A Practical Guide to Computer Security.iso / rfc / rfc1637.txt < prev    next >
Text File  |  1997-04-01  |  22KB  |  620 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         B. Manning
  8. Request for Comments: 1637                               Rice University
  9. Obsoletes: 1348                                               R. Colella
  10. Category: Experimental                                              NIST
  11.                                                                June 1994
  12.  
  13.  
  14.                        DNS NSAP Resource Records
  15.  
  16.  
  17. Status of this Memo
  18.  
  19.    This memo defines an Experimental Protocol for the Internet
  20.    community.  This memo does not specify an Internet standard of any
  21.    kind.  Discussion and suggestions for improvement are requested.
  22.    Distribution of this memo is unlimited.
  23.  
  24. Abstract
  25.  
  26.    The Internet is moving towards the deployment of an OSI lower layers
  27.    infrastructure. This infrastructure comprises the connectionless
  28.    network protocol (CLNP) and supporting routing protocols. Also
  29.    required as part of this infrastructure is support in the Domain Name
  30.    System (DNS) for mapping between names and NSAP addresses.
  31.  
  32.    This document defines the format of one new Resource Record (RR) for
  33.    the DNS for domain name-to-NSAP mapping. The RR may be used with any
  34.    NSAP address format. This document supercedes RFC 1348.
  35.  
  36.    NSAP-to-name translation is accomplished through use of the PTR RR
  37.    (see STD 13, RFC 1035 for a description of the PTR RR). This paper
  38.    describes how PTR RRs are used to support this translation.
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Manning & Colella                                               [Page 1]
  59.  
  60. RFC 1637                      DNS NSAP RRs                     June 1994
  61.  
  62.  
  63. 1.  Introduction
  64.  
  65.    The Internet is moving towards the deployment of an OSI lower layers
  66.    infrastructure. This infrastructure comprises the connectionless
  67.    network protocol (CLNP) [6] and supporting routing protocols. Also
  68.    required as part of this infrastructure is support in the Domain Name
  69.    System (DNS) [8] [9] for mapping between domain names and OSI Network
  70.    Service Access Point (NSAP) addresses [7] [Note: NSAP and NSAP
  71.    address are used interchangeably throughout this memo].
  72.  
  73.    This document defines the format of one new Resource Record (RR) for
  74.    the DNS for domain name-to-NSAP mapping. The RR may be used with any
  75.    NSAP address format.
  76.  
  77.    NSAP-to-name translation is accomplished through use of the PTR RR
  78.    (see RFC 1035 for a description of the PTR RR). This paper describes
  79.    how PTR RRs are used to support this translation.
  80.  
  81.    This memo assumes that the reader is familiar with the DNS. Some
  82.    familiarity with NSAPs is useful; see [2] or [7] for additional
  83.    information.
  84.  
  85. 2.  Background
  86.  
  87.    The reason for defining DNS mappings for NSAPs is to support CLNP in
  88.    the Internet. Debugging with CLNP ping and traceroute is becoming
  89.    more difficult with only numeric NSAPs as the scale of deployment
  90.    increases. Current debugging is supported by maintaining and
  91.    exchanging a configuration file with name/NSAP mappings similar in
  92.    function to hosts.txt. This suffers from the lack of a central
  93.    coordinator for this file and also from the perspective of scaling.
  94.    The former is the most serious short-term problem. Scaling of a
  95.    hosts.txt-like solution has well-known long-term scaling
  96.    difficiencies.
  97.  
  98.    A second reason for this work is the proposal to use CLNP as an
  99.    alternative to IP: "TCP and UDP with Bigger Addresses (TUBA), A
  100.    Simple Proposal for Internet Addressing and Routing" [1]. For this to
  101.    be practical, the DNS must be capable of supporting CLNP addresses.
  102.  
  103. 3.  Scope
  104.  
  105.    The methods defined in this paper are applicable to all NSAP formats.
  106.    This includes support for the notion of a custom-defined NSAP format
  107.    based on an AFI obtained by the IAB for use in the Internet.
  108.  
  109.    As a point of reference, there is a distinction between registration
  110.    and publication of addresses. For IP addresses, the IANA is the root
  111.  
  112.  
  113.  
  114. Manning & Colella                                               [Page 2]
  115.  
  116. RFC 1637                      DNS NSAP RRs                     June 1994
  117.  
  118.  
  119.    registration authority and the DNS a publication method. For NSAPs,
  120.    addendum two of the network service definition, ISO8348/Ad2 [7] is
  121.    the root registration authority and this memo defines how the DNS is
  122.    used as a publication method.
  123.  
  124. 4.  Structure of NSAPs
  125.  
  126.    NSAPs are hierarchically structured to allow distributed
  127.    administration and efficient routing. Distributed administration
  128.    permits subdelegated addressing authorities to, as allowed by the
  129.    delegator, further structure the portion of the NSAP space under
  130.    their delegated control.  Accomodating this distributed authority
  131.    requires that there be little or no a priori knowledge of the
  132.    structure of NSAPs built into DNS resolvers and servers.
  133.  
  134.    For the purposes of this memo, NSAPs can be thought of as a tree of
  135.    identifiers. The root of the tree is ISO8348/Ad2 [7], and has as its
  136.    immediately registered subordinates the one-octet Authority and
  137.    Format Identifiers (AFIs) defined there. The size of subsequently-
  138.    defined fields depends on which branch of the tree is taken. The
  139.    depth of the tree varies according to the authority responsible for
  140.    defining subsequent fields.
  141.  
  142.    An example is the authority under which U.S. GOSIP defines NSAPs [3].
  143.    Under the AFI of 47, NIST (National Institute of Standards and
  144.    Technology) obtained a value of 0005 (the AFI of 47 defines the next
  145.    field as being two octets consisting of four BCD digits from the
  146.    International Code Designator space [4]). NIST defined the subsequent
  147.    fields in [3], as shown in Figure 1. The field immediately following
  148.    0005 is a format identifier for the rest of the U.S. GOSIP NSAP
  149.    structure, with a hex value of 80. Following this is the three-octet
  150.    field, values for which are allocated to network operators; the
  151.    registration authority for this field is delegated to GSA (General
  152.    Services Administration).
  153.  
  154.    The last octet of the NSAP is the NSelector (NSel). In practice, the
  155.    NSAP minus the NSel identifies the CLNP protocol machine on a given
  156.    system, and the NSel identifies the CLNP user. Since there can be
  157.    more than one CLNP user (meaning multiple NSel values for a given
  158.    "base" NSAP), the representation of the NSAP should be CLNP-user
  159.    independent. To achieve this, an NSel value of zero shall be used
  160.    with all NSAP values stored in the DNS. An NSAP with NSel=0
  161.    identifies the network layer itself. It is left to the application
  162.    retrieving the NSAP to determine the appropriate value to use in that
  163.    instance of communication.
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Manning & Colella                                               [Page 3]
  171.  
  172. RFC 1637                      DNS NSAP RRs                     June 1994
  173.  
  174.  
  175.               |--------------|
  176.               | <-- IDP -->  |
  177.               |--------------|-------------------------------------|
  178.               | AFI |  IDI   |            <-- DSP -->              |
  179.               |-----|--------|-------------------------------------|
  180.               | 47  |  0005  | DFI | AA |Rsvd | RD |Area | ID |Sel |
  181.               |-----|--------|-----|----|-----|----|-----|----|----|
  182.        octets |  1  |   2    |  1  | 3  |  2  | 2  |  2  | 6  | 1  |
  183.               |-----|--------|-----|----|-----|----|-----|----|----|
  184.  
  185.                     IDP    Initial Domain Part
  186.                     AFI    Authority and Format Identifier
  187.                     IDI    Initial Domain Identifier
  188.                     DSP    Domain Specific Part
  189.                     DFI    DSP Format Identifier
  190.                     AA     Administrative Authority
  191.                     Rsvd   Reserved
  192.                     RD     Routing Domain Identifier
  193.                     Area   Area Identifier
  194.                     ID     System Identifier
  195.                     SEL    NSAP Selector
  196.  
  197.                   Figure 1: GOSIP Version 2 NSAP structure.
  198.  
  199.  
  200.    When CLNP is used to support TCP and UDP services, the NSel value
  201.    used is the appropriate IP PROTO value as registered with the IANA.
  202.    For "standard" OSI, the selection of NSel values is left as a matter
  203.    of local administration. Administrators of systems that support the
  204.    OSI transport protocol [5] in addition to TCP/UDP must select NSels
  205.    for use by OSI Transport that do not conflict with the IP PROTO
  206.    values.
  207.  
  208.    In the NSAP RRs in Master Files and in the printed text in this memo,
  209.    NSAPs are often represented as a string of "."-separated hex values.
  210.    The values correspond to convenient divisions of the NSAP to make it
  211.    more readable. For example, the "."-separated fields might correspond
  212.    to the NSAP fields as defined by the appropriate authority (ISOC,
  213.    RARE, U.S. GOSIP, ANSI, etc.). The use of this notation is strictly
  214.    for readability. The "."s do not appear in DNS packets and DNS
  215.    servers can ignore them when reading Master Files. For example, a
  216.    printable representation of the first four fields of a U.S. GOSIP
  217.    NSAP might look like
  218.  
  219.                              47.0005.80.005a00
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Manning & Colella                                               [Page 4]
  227.  
  228. RFC 1637                      DNS NSAP RRs                     June 1994
  229.  
  230.  
  231.    and a full U.S. GOSIP NSAP might appear as
  232.  
  233.              47.0005.80.005a00.0000.1000.0020.00800a123456.00.
  234.  
  235.    Other NSAP formats have different lengths and different
  236.    administratively defined field widths to accomodate different
  237.    requirements. For more information on NSAP formats in use see RFC
  238.    1629 [2].
  239.  
  240. 5.  The NSAP RR
  241.  
  242.    The NSAP RR is defined with mnemonic "NSAP" and TYPE code 22
  243.    (decimal) and is used to map from domain names to NSAPs. Name-to-NSAP
  244.    mapping in the DNS using the NSAP RR operates analogously to IP
  245.    address lookup. A query is generated by the resolver requesting an
  246.    NSAP RR for a provided domain name.
  247.  
  248.    NSAP RRs conform to the top level RR format and semantics as defined
  249.    in Section 3.2.1 of RFC 1035.
  250.  
  251.                                             1  1  1  1  1  1
  252.               0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
  253.            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  254.            |                                               |
  255.            /                                               /
  256.            /                        NAME                   /
  257.            |                                               |
  258.            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  259.            |                    TYPE = NSAP                |
  260.            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  261.            |                    CLASS = IN                 |
  262.            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  263.            |                        TTL                    |
  264.            |                                               |
  265.            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  266.            |                      RDLENGTH                 |
  267.            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  268.            /                       RDATA                   /
  269.            /                                               /
  270.            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  271.  
  272.    where:
  273.  
  274.    *  NAME: an owner name, i.e., the name of the node to which this
  275.       resource record pertains.
  276.  
  277.    *  TYPE: two octets containing the NSAP RR TYPE code of 22 (decimal).
  278.  
  279.  
  280.  
  281.  
  282. Manning & Colella                                               [Page 5]
  283.  
  284. RFC 1637                      DNS NSAP RRs                     June 1994
  285.  
  286.  
  287.    *  CLASS: two octets containing the RR IN CLASS code of 1.
  288.  
  289.    *  TTL: a 32 bit signed integer that specifies the time interval in
  290.       seconds that the resource record may be cached before the source
  291.       of the information should again be consulted. Zero values are
  292.       interpreted to mean that the RR can only be used for the
  293.       transaction in progress, and should not be cached. For example,
  294.       SOA records are always distributed with a zero TTL to prohibit
  295.       caching. Zero values can also be used for extremely volatile data.
  296.  
  297.    *  RDLENGTH: an unsigned 16 bit integer that specifies the length in
  298.       octets of the RDATA field.
  299.  
  300.    *  RDATA: a variable length string of octets containing the NSAP.
  301.       The value is the binary encoding of the NSAP as it would appear in
  302.       the CLNP source or destination address field. A typical example of
  303.       such an NSAP (in hex) is shown below. For this NSAP, RDLENGTH is
  304.       20 (decimal); "."s have been omitted to emphasize that they don't
  305.       appear in the DNS packets.
  306.  
  307.                  39840f80005a0000000001e13708002010726e00
  308.  
  309. 5.1  Additional Section Processing
  310.  
  311.    [The specification in this section is necessary for completeness in
  312.    describing name server support for TUBA. For the time being, name
  313.    servers participating in TUBA demonstrations MAY ELECT to implement
  314.    this behavior; it SHOULD NOT be the default behavior of name servers
  315.    because the IPng sweepstakes are still outstanding and further
  316.    consideration is required for truncation and other issues.]
  317.  
  318.    RFC 1035 describes the additional section processing (ASP) required
  319.    when servers encounter NS records during query processing. From
  320.    Section 3.3.11, "NS RDATA format":
  321.  
  322.       NS records cause both the usual additional section processing to
  323.       locate a type A record, and, when used in a referral, a special
  324.       search of the zone in which they reside for glue information.
  325.  
  326.    For TUBA, identical ASP is required on type NSAP records to support
  327.    servers and resolvers that use CLNP, either because of preference or
  328.    because it is the only internetworking protocol available (i.e., in
  329.    the absense of IPv4). Thus, NS records cause ASP which locates a type
  330.    NSAP record in addition to a type A record. Both type A and NSAP
  331.    records should be returned, if available.
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Manning & Colella                                               [Page 6]
  339.  
  340. RFC 1637                      DNS NSAP RRs                     June 1994
  341.  
  342.  
  343. 6.  NSAP-to-name Mapping Using the PTR RR
  344.  
  345.    The PTR RR is defined in RFC 1035. This RR is typically used under
  346.    the "IN-ADDR.ARPA" domain to map from IPv4 addresses to domain names.
  347.  
  348.    Similarly, the PTR RR is used to map from NSAPs to domain names under
  349.    the "NSAP.INT" domain. A domain name is generated from the NSAP
  350.    according to the rules described below. A query is sent by the
  351.    resolver requesting a PTR RR for the provided domain name.
  352.  
  353.    A domain name is generated from an NSAP by reversing the hex nibbles
  354.    of the NSAP, treating each nibble as a separate subdomain, and
  355.    appending the top-level subdomain name "NSAP.INT" to it. For example,
  356.    the domain name used in the reverse lookup for the NSAP
  357.  
  358.              47.0005.80.005a00.0000.0001.e133.ffffff000162.00
  359.  
  360.    would appear as
  361.  
  362.      0.0.2.6.1.0.0.0.f.f.f.f.f.f.3.3.1.e.1.0.0.0.0.0.0.0.0.0.a.5.0.0. \
  363.                          0.8.5.0.0.0.7.4.NSAP.INT.
  364.  
  365.    [Implementation note: For sanity's sake user interfaces should be
  366.    designed to allow users to enter NSAPs using their natural order,
  367.    i.e., as they are typically written on paper. Also, arbitrary "."s
  368.    should be allowed (and ignored) on input.]
  369.  
  370. 7.  Master File Format
  371.  
  372.    The format of NSAP RRs (and NSAP-related PTR RRs) in Master Files
  373.    conforms to Section 5, "Master Files," of RFC 1035. Below are
  374.    examples of the use of these RRs in Master Files to support name-to-
  375.    NSAP and NSAP-to-name mapping.
  376.  
  377.    The NSAP RR introduces a new hex string format for the RDATA field.
  378.    The format is "0x" (i.e., a zero followed by an 'x' character)
  379.    followed by a variable length string of hex characters (0 to 9, a to
  380.    f). The hex string is case-insensitive. "."s (i.e., periods) may be
  381.    inserted in the hex string anywhere after the "0x" for readability.
  382.    The "."s have no significance other than for readability and are not
  383.    propagated in the protocol (e.g., queries or zone transfers).
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Manning & Colella                                               [Page 7]
  395.  
  396. RFC 1637                      DNS NSAP RRs                     June 1994
  397.  
  398.  
  399.    ;;;;;;
  400.    ;;;;;; Master File for domain nsap.nist.gov.
  401.    ;;;;;;
  402.  
  403.  
  404.    @      IN     SOA    emu.ncsl.nist.gov.  root.emu.ncsl.nist.gov. (
  405.                                      1994041800   ; Serial  - date
  406.                                      1800         ; Refresh - 30 minutes
  407.                                      300          ; Retry   - 5 minutes
  408.                                      604800       ; Expire  - 7 days
  409.                                      3600 )       ; Minimum - 1 hour
  410.           IN     NS     emu.ncsl.nist.gov.
  411.           IN     NS     tuba.nsap.lanl.gov.
  412.    ;
  413.    ;
  414.    $ORIGIN nsap.nist.gov.
  415.    ;
  416.    ;     hosts
  417.    ;
  418.    bsdi1    IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.ffffff000161.00
  419.             IN  A      129.6.224.161
  420.             IN  HINFO PC_486    BSDi1.1(TUBA)
  421.    ;
  422.    bsdi2    IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.ffffff000162.00
  423.             IN  A      129.6.224.162
  424.             IN  HINFO PC_486    BSDi1.1(TUBA)
  425.    ;
  426.    cursive  IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.ffffff000171.00
  427.             IN  A      129.6.224.171
  428.             IN  HINFO PC_386    DOS_5.0/NCSA_Telnet(TUBA)
  429.    ;
  430.    infidel  IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.ffffff000164.00
  431.             IN  A      129.6.55.164
  432.             IN  HINFO PC/486    BSDi1.0(TUBA)
  433.    ;
  434.    ;     routers
  435.    ;
  436.    cisco1   IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.aaaaaa000151.00
  437.             IN  A      129.6.224.151
  438.             IN  A      129.6.225.151
  439.             IN  A      129.6.229.151
  440.    ;
  441.    3com1    IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.aaaaaa000111.00
  442.             IN  A      129.6.224.111
  443.             IN  A      129.6.225.111
  444.             IN  A      129.6.228.111
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Manning & Colella                                               [Page 8]
  451.  
  452. RFC 1637                      DNS NSAP RRs                     June 1994
  453.  
  454.  
  455.    ;;;;;;
  456.    ;;;;;; Master File for reverse mapping of NSAPs under the
  457.    ;;;;;;     NSAP prefix:
  458.    ;;;;;;
  459.    ;;;;;;          47.0005.80.005a00.0000.0001.e133
  460.    ;;;;;;
  461.  
  462.  
  463.    @      IN     SOA    emu.ncsl.nist.gov.  root.emu.ncsl.nist.gov. (
  464.                                      1994041800   ; Serial  - date
  465.                                      1800         ; Refresh - 30 minutes
  466.                                      300          ; Retry   - 5 minutes
  467.                                      604800       ; Expire  - 7 days
  468.                                      3600 )       ; Minimum - 1 hour
  469.           IN     NS     emu.ncsl.nist.gov.
  470.           IN     NS     tuba.nsap.lanl.gov.
  471.    ;
  472.    ;
  473.    $ORIGIN 3.3.1.e.1.0.0.0.0.0.0.0.0.0.a.5.0.0.0.8.5.0.0.0.7.4.NSAP.INT.
  474.    ;
  475.    0.0.1.6.1.0.0.0.f.f.f.f.f.f  IN    PTR  bsdi1.nsap.nist.gov.
  476.    ;
  477.    0.0.2.6.1.0.0.0.f.f.f.f.f.f  IN    PTR  bsdi2.nsap.nist.gov.
  478.    ;
  479.    0.0.1.7.1.0.0.0.f.f.f.f.f.f  IN    PTR  cursive.nsap.nist.gov.
  480.    ;
  481.    0.0.4.6.1.0.0.0.f.f.f.f.f.f  IN    PTR  infidel.nsap.nist.gov.
  482.    ;
  483.    0.0.1.5.1.0.0.0.a.a.a.a.a.a  IN    PTR  cisco1.nsap.nist.gov.
  484.    ;
  485.    0.0.1.1.1.0.0.0.a.a.a.a.a.a  IN    PTR  3com1.nsap.nist.gov.
  486.  
  487. 8.  Security Considerations
  488.  
  489.    Security issues are not discussed in this memo.
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Manning & Colella                                               [Page 9]
  507.  
  508. RFC 1637                      DNS NSAP RRs                     June 1994
  509.  
  510.  
  511. 9.  Authors' Addresses
  512.  
  513.    Bill Manning
  514.    Rice University -- ONCS
  515.    P.O. Box 1892
  516.    6100 South Main
  517.    Houston, Texas 77251-1892
  518.    USA
  519.  
  520.    Phone: +1.713.285.5415
  521.    EMail: bmanning@rice.edu
  522.  
  523.  
  524.    Richard Colella
  525.    National Institute of Standards and Technology
  526.    Technology/B217
  527.    Gaithersburg, MD 20899
  528.    USA
  529.  
  530.    Phone: +1 301-975-3627
  531.    Fax: +1 301 590-0932
  532.    EMail: colella@nist.gov
  533.  
  534. 10.  References
  535.  
  536.    [1] Callon R., "TCP and UDP with Bigger Addresses (TUBA), A Simple
  537.        Proposal for Internet Addressing and Routing", RFC 1347, DEC,
  538.        June 1992.
  539.  
  540.    [2] Colella, R., Gardner, E., Callon, R., and Y. Rekhter, "Guidelines
  541.        for OSI NSAP Allocation inh the Internet", RFC 1629, NIST,
  542.        Wellfleet, Mitre, T.J. Watson Research Center, IBM Corp., May
  543.        1994.
  544.  
  545.    [3] GOSIP Advanced Requirements Group.  Government Open Systems
  546.        Interconnection Profile (GOSIP) Version 2. Federal Information
  547.        Processing Standard 146-1, U.S. Department of Commerce, National
  548.        Institute of Standards and Technology, Gaithersburg, MD, April
  549.        1991.
  550.  
  551.    [4] ISO/IEC.  Data interchange - structures for the identification of
  552.        organization.  International Standard 6523, ISO/IEC JTC 1,
  553.        Switzerland, 1984.
  554.  
  555.    [5] ISO/IEC. Connection oriented transport protocol specification.
  556.        International Standard 8073, ISO/IEC JTC 1, Switzerland, 1986.
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Manning & Colella                                              [Page 10]
  563.  
  564. RFC 1637                      DNS NSAP RRs                     June 1994
  565.  
  566.  
  567.    [6] ISO/IEC.  Protocol for Providing the Connectionless-mode Network
  568.        Service.  International Standard 8473, ISO/IEC JTC 1,
  569.        Switzerland, 1986.
  570.  
  571.    [7] ISO/IEC. Information Processing Systems -- Data Communications --
  572.        Network Service Definition Addendum 2: Network Layer Addressing.
  573.        International Standard 8348/Addendum 2, ISO/IEC JTC 1,
  574.        Switzerland, 1988.
  575.  
  576.    [8] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
  577.        13, RFC 1034, USC/Information Sciences Institute, November 1987.
  578.  
  579.    [9] Mockapetris, P., "Domain Names -- Implementation and
  580.        Specification", STD 13, RFC 1035, USC/Information Sciences
  581.        Institute, November 1987.
  582.  
  583.  
  584.  
  585.  
  586.  
  587.  
  588.  
  589.  
  590.  
  591.  
  592.  
  593.  
  594.  
  595.  
  596.  
  597.  
  598.  
  599.  
  600.  
  601.  
  602.  
  603.  
  604.  
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Manning & Colella                                              [Page 11]
  619.  
  620.